home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 8: LINUX Games / Linux Cubed Series 8 - LINUX Games.iso / games / x11 / rpg / crossfir.000 / crossfir / crossfire-0.92.4.client / README < prev    next >
Text File  |  1996-04-21  |  8KB  |  191 lines
  1. This is the client distribution.  It is still in developement, but
  2. may be of interest to those who plan to do work, or just want tto see
  3. how it works so far.
  4.  
  5. To use the client, do the following:
  6.  
  7. Change the configurable options in the Imakefile.  The configurable ones
  8. are those at the start of the file.
  9.  
  10. make the makefiles ("xmkmf -a")
  11.  
  12. Install the eutl package, and make sure that is compiled (likewise, you
  13. may need to make some changes in the configuration of the Imakefile
  14. to be set up correctly).
  15.  
  16.  type 'make'.
  17.  
  18. You must also have/know of a server that supports the new client code.
  19.  
  20. You must also have the keybindings file installed.  Best way to do
  21. this is "mkdir ~/.crossfire" "cp def_keys ~/.crossfire/keys".
  22. This file contains all the keybinds.
  23.  
  24. You can now run the client.  In general, all you need to do 
  25. "cfclient -server <servername>", where <servername> is the host name
  26. that is running a new server.  -port will specify a different port.
  27. You can do "cfclient -h" to see a full list of options.
  28.  
  29. ------------------------------------------------------------------------------
  30. This is the early stages of the new client server model.
  31.  
  32. My goal for the client is to try and limit all the windowing stuff
  33. to one file.  In this way, porting to other window systems (or
  34. just different toolkits) should only require replacing that one file,
  35. with hopefully no changes in the rest of the code.
  36.  
  37. In the ../server directory, changes have been made.  All of them
  38. shoulde be #ifdef NEW_CS  In some cases, if the change does not
  39. make the code incompatible, the #ifdef may not be in place.
  40.  
  41. In general, my working order on the client and server is in the order
  42. that the client would make requests, and what the server sends back.
  43. Thus, a bit of the initialization routines are done, but not a lot else.
  44.  
  45. Other notes:  As of now, I plan to use the generic libcross library for a
  46. lot of the code (it exists, and works).  Thus, player inventory, and in fact
  47. most code dealing with objects, will use the routines in the common/object.c
  48. file.  This should be redone sometime in the future - the object structure
  49. used in the games stores a lot more information than what the client will
  50. ever use.
  51.  
  52. The x11.c file is based on the server/xio.c file, with some changes
  53. made.  Only the code that has been modified is active, the rest
  54. if #ifdef'd out.  Some of the #ifdef'd code is out of date.
  55.  
  56. Using the player structure (in include/structs.h) will not happen.  That
  57. has a lot of information that will not be needed, and other stuff the
  58. is window system dependant (which, as said above, needs to be in
  59. x11.c).
  60.  
  61.  If interested in working on some of this code, send me mail, along
  62. with what you plan on working with.  I will make sure that other
  63. people do not work on the same area, and thus waste each others
  64. time.  Please, only send me mail saying you plan on working if you actually
  65. expect to be able to got the work done in a reasonable amount of time
  66. (since you will probably be working on just one of the protocol commands,
  67. this might be around a month, but will vary.)  Otherwise, if you say
  68. you plan to get some of the code done, no one else will be working on
  69. it, and it may never get done.
  70.  
  71. Mark Wedel
  72. master@rahul.net
  73.  
  74. ------------------------------------------------------------------------------
  75. GENERAL IDEA IN THE CLIENT:
  76.  
  77.  The overall working idea of the client is this:
  78.  
  79. 1) Initialize all structures, and read in local data (archetypes,
  80.    images, etc)
  81.  
  82. 2) Depending on flags, request missing data from server.
  83.  
  84. 3) Login to server
  85.  
  86. 4) It then repeats the following:
  87.    a) Check to see if new data has been received from the server
  88.    b) Check to see if any X events need to be processed
  89.    c) update all appropriate displays (might be done in calls in
  90.     a and b above)
  91.    d) See if we need to request more data from server, and do so
  92.  
  93.  
  94.  There is cases where depending on certain actions, the loop in stage
  95. 4 jumps to stage 3 (character dies, player wants to start new character,
  96. etc).
  97.  
  98.  Dealing with missing data:
  99.  
  100.  At times, the archetype or image sent in an ITEM command is missing.
  101. In that case, it needs to be requested from the server.  But there is
  102. a lag in this time.  This is how it is handled:
  103.  
  104. Archetypes:  Archetype data isn't needed, but it is very
  105. convenient (gives animations, and basic properties.)  When an archetype
  106. not known by the client is sent, the client sets the slaying field
  107. in the object to the archetype name, and adds that name to the list
  108. of archetypes to request from the server.
  109.  
  110. When the archetype is then received, the client goes through all the
  111. objects (shouldn't be that many), and any with the matching slaying
  112. field are processed (assigned that archetype, and slaying field
  113. is freed and reset.)
  114.  
  115. Images:  When an image is missing, the client assigns an image number
  116. that will be used when that image arrives.  In the meantime, that
  117. pixmap number is assigned to some other already used number (
  118. right now, it is the stipple1 face.)  When the actual image
  119. arrives, the pixmap is then updated with this newly created image.
  120. The update is then automatic the next time the image is drawn - instead
  121. of using the stipple face that was assigned to that pixmap entry, it
  122. will use the new face that was downloaded.
  123.  
  124.  Note that in font mode, the stipple face id will still be assigned,
  125. but new images can not be downloaded.  Thus, for the remainder of
  126. the session, the stipple image will be used for that object.
  127.  
  128.  
  129. ------------------------------------------------------------------------------
  130. SERVER buffering/not buffering commands:
  131.  
  132.  This is a description of how the server handles buffering, and what
  133. some of the elements in the socket structure mean regarding this.
  134.  
  135.  If command buffering is not set (default), then the server reads
  136. the data from the socket.  It processes all that data, and actual
  137. player commands are then executed.  If the player has insufficient
  138. time to perform such an action, then that action is not performed, but
  139. the data is dropped from the input stream.  Input is still processed
  140. until there is not input to read - thus many commands could be
  141. dropped. (note that the protocol contains many commands which
  142. the player does not execute, or that take 0 time.  These will continue
  143. to be processed.  All commands that take player time will be dropped
  144. until the player gains sufficient time.)
  145.  
  146.  If command buffering is set, then the buffer_data element in the
  147. socket is set.
  148.  
  149.  Data is read in as before.  This data is processed until it is either
  150. all gone, or until the player runs out of time to execute more
  151. commands (at which time, commands_blocked will be set.)
  152.  
  153.  No further input processing happens at this time - the input that was
  154. already read from the socket but not yer processed is stored in the save_buf
  155. element.
  156.  
  157.  In future loops, if the socket is no longer blocked,
  158. then the data that is in the save_buf is processed.  If after processing
  159. this data, commands_blocked is still not set, then more data is read
  160. from the socket, and processed.
  161.  
  162. The downside of this is twofold:  1) the input buffer could
  163. overflow (not very likely unless the player is very slow or sending
  164. a lot of commands), and 2) Even commands that take 0 time are
  165. not processed.
  166.  
  167.  Smarter processing of the input buffer should probably be done
  168. at some time.  But this becomes very difficult, because the ordering
  169. of the commands is relevant.  While a look_at command could perhaps
  170. be a 0 time command, incorrect results would possibly be given
  171. if player movements are in the buffer waiting to be processed.
  172.  
  173. ------------------------------------------------------------------------------
  174. Player's speed:
  175.  
  176.  In the 'old' method, the players speed was increased.  Then,
  177. assuming he had sufficient speed, handle_player was called.  This
  178. would then take care of movement or any other commands, all of which
  179. took time of 1.0.  If after handle_player was called he still had
  180. time, it would be called again (having sufficient time could be due to 
  181. a speed > 1.0, or if in combat, in which case weapon_sp is used.)
  182.  
  183.  In the new method, commands are handled when data is read from the
  184. socket, not in handle_player.  As such, when data is read in, the
  185. appropriate command is performed.  When the player runs out of time,
  186. he will not perform any more actions (what happens to the data
  187. is determined by buffereing, see above.)
  188.  
  189.  Commands have variable times.  Putting on armour takes long than
  190. picking up a coin.
  191.